Healthcare system integration

ABSTRACT

An approach is provided for acquiring and integrating data into external services. According to the approach, image and/or video data and identification data are received from a client device. The image and/or video data includes one or more images and/or video data of an object that are acquired by the client device and the identification data is data that uniquely identifies the object. Record data is generated and stored that includes the identification data and at least a reference to the image and/or video data. The image and/or video data and the identification data are transmitted to an external service. This identification data allows an external service to associate the image and/or video data with other data maintained by the external service.

RELATED APPLICATION DATA AND CLAIM OF PRIORITY

This application is a Continuation of prior U.S. patent application Ser.No. 13/946,650, now U.S. Pat. No. 9,275,349, entitled “Healthcare SystemIntegration”, filed Jul. 19, 2013, the contents of which areincorporated by reference for all purposes as if fully set forth herein.

This application is related to U.S. patent application Ser. No.13/946,639 entitled “Auto Insurance System Integration”, filed Jul. 19,2013, the contents all of which are incorporated by reference in theirentirety for all purposes as if fully set forth herein.

FIELD OF THE INVENTION

Embodiments relate generally to acquiring and integrating data intoexternal services, and more specifically, to streamlining the process ofacquiring and integrating data into external services.

BACKGROUND

The approaches described in this section are approaches that could bepursued, but not necessarily approaches that have been previouslyconceived or pursued. Therefore, unless otherwise indicated, it shouldnot be assumed that any of the approaches described in this sectionqualify as prior art merely by virtue of their inclusion in thissection.

An increasing number of mobile devices, such as smartphones and tabletcomputers, are equipped with cameras. This makes them increasinglyvaluable to individuals and businesses. One of the issues with mobiledevices that include cameras is that it can be difficult for businessusers to upload acquired images to external services, such as businessapplications. Users typically do not have the specialized knowledge orskills to access the interfaces provided by external services andtherefore must rely upon dedicated applications executing on theirmobile devices to be able to upload images from their mobile devices toexternal services. Even with such dedicated applications, it can bedifficult for users to associate images with particular data recordsmanaged by the external services.

SUMMARY

An approach is provided for integrating data into an electronic medicalrecord system. Both first image data associated with a first patient andfirst identification data that uniquely identifies the first patient arereceived from a first client device having at least a data acquisitioncomponent. First record data is generated and stored that includes thefirst identification data and at least a reference to the first imagedata. Both second image data associated with a second patient and secondidentification data that uniquely identifies the second patient arereceived from a second client device having at least a data acquisitioncomponent. Second record data is generated and stored that includes thesecond identification data and at least a reference to the second imagedata. The first image data associated with the first patient, the firstidentification data that uniquely identifies the first patient, thesecond image data associated with the second patient and the secondidentification data that uniquely identifies the second patient aretransmitted to an electronic medical record system that is external tothe apparatus.

BRIEF DESCRIPTION OF THE DRAWINGS

In the figures of the accompanying drawings like reference numeralsrefer to similar elements.

FIGS. 1A-1E are block diagrams that depict arrangements for acquiringand integrating data into external services.

FIG. 2 is a flow diagram that depicts an approach for configuring aclient device to transmit acquired data to a processing service.

FIG. 3A is a flow diagram that depicts an approach for acquiring datawith a client device and transferring the acquired data to a processingservice.

FIG. 3B depicts an example graphical user interface that allows a userto select image data and scan data acquired at the site of an automobileaccident and transfer the selected image data and scan data to an autoinsurance service.

FIGS. 4A and 4B are example photos of an automobile that has beeninvolved in an accident.

FIGS. 4C and 4D are example photos of a location of an automobileaccident.

FIG. 5A depicts a table of example memo information that may be enteredby a user for an automobile involved in an accident.

FIG. 5B depicts a table of example memo information that may be enteredby a user for a patient in the electronic medical record (EMR) context.

FIGS. 6A and 6B depicts a graphical user interface of a client device inthe form of a camera that displays a region on a patient's body.

FIGS. 7A-7C are flow diagrams that depict example approaches for aprocessing service to receive acquired data from client device.

FIG. 8A depicts an example data structure implemented by a processingservice in the auto insurance context.

FIG. 8B depicts an example data structure implemented by a processingservice in the EMR context.

FIG. 9 is a flow diagram that depicts an approach for transferringacquired data to external services.

FIG. 10 depicts an example administrator login screen that may beimplemented as a Web page.

FIGS. 11A and 11B depict example administrative user interface screensin the auto insurance context.

FIGS. 12A and 12B depict example administrative user interface screensin the EMR context.

FIG. 13 is a block diagram that depicts an example computer system uponwhich embodiments may be implemented.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the embodiments. It will be apparent, however, to oneskilled in the art that the embodiments may be practiced without thesespecific details. In other instances, well-known structures and devicesare shown in block diagram form in order to avoid unnecessarilyobscuring the embodiments.

I. OVERVIEW

II. SYSTEM ARCHITECTURE

-   -   A. Client Device    -   B. Processing Service

III. CLIENT DEVICE CONFIGURATION AND DATA ACQUISITION

IV. DATA RECEPTION AND PROCESSING

V. TRANSFERRING ACQUIRED DATA TO EXTERNAL SERVICES

VI. PROCESSING SERVICE ADMINISTRATION

VII. IMPLEMENTATION MECHANISMS

I. Overview

An approach is provided for acquiring and integrating data into externalservices. According to the approach, image and/or video data andidentification data are received from a client device. The image and/orvideo data includes one or more images and/or video data of an objectthat are acquired by the client device and the identification data isdata that uniquely identifies the object. Record data is generated andstored that includes the identification data and at least a reference tothe image and/or video data. The image and/or video data and theidentification data are transmitted to an external service. Thisidentification data allows an external service to associate the imageand/or video data with other data maintained by the external service.

The approach is beneficial in a wide variety of contexts in which ithelpful for a user to upload acquired data to external services and havethe acquired data automatically associated with other data maintained bythe external services. For example, the approach may be useful in theauto insurance industry to allow a user to use a client device, such asa camera, smartphone, tablet computer, etc., to acquire image and/orvideo data of an automobile involved in an accident, upload the imageand/or video data to an auto insurance system and have the image and/orvideo data be automatically associated with insurance claim recordsmaintained by the auto insurance system. As another example, theapproach may be useful in the electronic medical record industry toallow a user to use a client device to acquire image and/or video dataof a patient, upload the image and/or video data to an electronicmedical record system and have the image and/or video data automaticallyassociated with records for the patient maintained by the electronicmedical record system. In both examples, the user does not need to havespecific knowledge of the interfaces or other mechanisms used to uploadthe acquired data to the auto insurance system or the electronic medicalrecord system. The approach is applicable to integrating into externalservices data acquired by multiple client devices.

II. System Architecture

FIG. 1A is a block diagram that depicts an arrangement 100 for acquiringand integrating data into external services. Arrangement 100 includes aclient device 102, a processing service 104, an auto insurance system106, an electronic medical record (EMR) system 108 and other services110. Arrangement 100 is not limited the particular elements depicted inFIG. 1A and may include fewer or additional elements depending upon aparticular implementation. Embodiments are described herein in thecontext of a single client device 102 for purposes of explanation, butthe approach is applicable to any number of client devices. The variouselements depicted in FIG. 1A are communicatively coupled via one or morecommunications links that may include, for example, any number and typeof wired or wireless networks, such as local area networks (LANs), widearea networks (WANs), the Internet, etc., as well as directcommunications links.

A. Client Device

Client device 102 is configured to perform data acquisition and transmitthe acquired data to other devices. According to one embodiment, clientdevice 102 is configured to acquire image and/or video data of object116 and identification data that uniquely identifies object 116 andtransmit the acquired image and/or video data and identification data toother devices. For example, in the context of object 116 being anautomobile, client device 102 may acquire image and/or video data of theautomobile and identification data that uniquely identifies theautomobile and transmit the image and/or video data and identificationdata to processing service 104. As another example, in the context ofobject 116 being a human patient, client device 102 may acquire imageand/or video data of the patient and identification data that uniquelyidentifies the patient and transmit the image and/or video data andidentification data to processing service 104.

In the example depicted in FIG. 1A, client device 102 includes a userinterface 112 and a data acquisition component 114. User interface 112allows for the exchange of information between a user and client device102. For example, user interface 112 may include a display fordisplaying information to a user. User interface 112 may also includecontrols to allow a user to enter information to client device 102. Thecontrols may be physical controls, such as buttons, switches, sliders,etc., or in the context of user interface 112 displaying a graphicaluser interface, the controls may be graphical user interface controls,such as buttons, dialog boxes, etc. User interface 112 may also includea touch screen for receiving user input. According to one embodiment,user interface 112 allows a user to acquire image and/or video data andidentification data using client device 102, and to cause the acquireddata to be transmitted to processing service 104, as described in moredetail hereinafter.

Client device 102 includes a data acquisition component 114 foracquiring identification data that uniquely identifies object 116. Theidentification data may be any type of data that uniquely identifiesobject 116. Examples of identification data include, without limitation,an identification number, a serial number, an identification code(numeric or alphanumeric), a symbol, or other information. Theidentification data may be in human readable form, such as a numeric oralphanumeric string. Alternatively, the identification code may be in anencoded form, for example, in the form of a bar code, a QR code, asignature, or other encoded data. Data acquisition component 114 mayalso acquire image or video data of object 116.

Data acquisition component 114 may comprise hardware subcomponents,programmable subcomponents, or both. For example, data acquisitioncomponent 114 may include one or more cameras, scanners, memory units orother data storage units, buffers and code instructions for acquiring,storing and transmitting data, or any combination thereof. Dataacquisition component 114 may be configured with a Wi-Fi interface and abarcode reader. The Wi-Fi interface may be used to transmit informationto and from the data acquisition component 114. The barcode reader maybe used to scan or otherwise acquire a code, such as a point of sale(POS) code displayed on an item. Client device 102 may be implemented bya wide variety of devices that may vary depending upon a particularimplementation and the invention is not limited to client device 102being implemented by any particular type of device. Examples of clientdevice 102 include, without limitation, a camera, a smart phone, atablet computer, a laptop computer, a personal digital assistant, avideo recorder, or wearable computing devices such as smart watches,body or head cams, or eye glasses, such as Google Glass by Google, Inc.,any of which configured with or without a scanner, such as a barcodescanner, a QR code scanner, etc., a scanner or other devices configuredto acquire data and transmit the acquired data to other devices.

Client device 102 may include other components that may vary dependingupon a particular implementation. According to one embodiment, clientdevice 102 includes a location component that is capable of determininga current location of client device 102 and generating location datathat indicates the current location of client device 102. Onenon-limiting example of a location component is a GPS module that candetermine the current position of the client device 102 and generatedata that indicates the GPS coordinates of that location. The GPS modulemay be internal or external to client device 102.

B. Processing Service

Processing service 104 receives image and/or video data andidentification data (“acquired data”) from client device 102 andintegrates the acquired data into auto insurance system 106, EMR system108 and other services 110. Processing service 104 may also process theacquired data as described in more detail hereinafter. Processingservice 104 may include various hardware and software components thatmay vary depending upon a particular implementation and processingservice 104 is not limited to any particular hardware and softwarecomponents. In the example depicted in FIG. 1A, processing service 104includes a data receiver 118, an integration service 120, a datatransmitter 122, a user interface 124 and storage 126. Processingservice 104 is not limited to the particular example depicted in FIG. 1Aand may include fewer or additional elements depending upon a particularimplementation.

Data receiver 118 is configured to receive data from client device 102and may do so using various communication protocols and from variousmedia. Example protocols include, without limitation, the File TransferProtocol (FTP), the Telnet Protocol, the Transmission Control Protocol(TCP), the TCP/Internet Protocol (TCP/IP), the Hypertext TransferProtocol (HTTP), the Simple Mail Transfer Protocol (SMTP), or any otherdata communications protocol. Data receiver 118 may be configured toread data from an FTP folder, an email folder, a Web server, a remotemedia such as a memory stick, or any other media.

For example, FIG. 1B depicts arrangement 100 as in FIG. 1A, except thatin FIG. 1B, client device 102 includes an FTP client 130 and processingservice 104 includes an FTP server 132. FTP server 132 is depicted inFIG. 1B as a separate element within processing service 104 for purposesof explanation only and FTP server 132 may be integrated into otherelements within processing service 104, such as data receiver 118,depending upon a particular implementation. In this example, an FTPfolder is created on storage 126 for storing acquired data received fromclient device 102. Client device 102 acquires image and/or video dataand identification data and FTP client 1128 causes the acquired data tobe transmitted to FTP server 132 on processing service 104 and stored inthe FTP folder on storage 126. Data receiver 118 retrieves the acquireddata from the FTP folder on storage 126 and transmits the retrieved datato integration service 120.

As another example, FIG. 1C depicts arrangement 100 as in FIG. 1A,except that in FIG. 1C, an email server 134 is provided and processingservice 104 includes an email client 136. Email client 136 is depictedin FIG. 1C as a separate element within processing service 104 forpurposes of explanation only and email client 136 may be integrated intoother elements within processing service 104, such as data receiver 118.Client device 102 acquires image and/or video data and identificationdata and FTP client 1128 causes the acquired data to be transmitted toemail server 134 via email. The acquired data may be embedded within anemail or attached to the email as one or more attachments. Email client136 retrieves the email from email server 134. Data receiver 118 obtainsthe email from email client 136, extracts or detaches the acquired datafrom the email and provides the acquired data to integration service120. The data extraction/detachment may alternatively be performed byemail client 136.

As another example, FIG. 1D depicts arrangement 100 as in FIG. 1A,except that in FIG. 1D, client device 102 includes an http client 138and processing service 104 includes a Web server 140. In this example,client device 102 provides image or video data and identification datato processing service 104 by http client 138 issuing http POST commandsto Web server 140. Data receiver 118 obtains the image and/or video dataand identification data from Web server 140 and provides the data tointegration service 120.

Integration service 120 is configured generally to receive data fromdata receiver 118, process the received data, and provide the data todata transmitter 122. As described in more detail hereinafter, this mayinclude generating and/or updating record data stored in storage 126.Storage 126 may include any type of storage, such as volatile memoryand/or non-volatile memory. Data transmitter 122 is configured toprovide image and/or video data and identification data to autoinsurance system 106, EMR system 108 and other services 110. Datatransmitter 122 transmits the data to auto insurance system 106, EMRsystem 108 and other services 110 using standard techniques oralternatively, data transmitter 122 may transmit data to auto insurancesystem 106, EMR system 108 and other services 110 in accordance withApplication Program Interfaces (APIs) supported by auto insurance system106, EMR system 108 and other services 110.

User interface 124 provides a mechanism for a user, such as anadministrator, to access processing service 104 and data stored onstorage 126, as described in more detail hereinafter. User interface 124may be implemented as an API for processing service 104. Alternatively,user interface 124 may be implemented by other mechanisms. For example,user interface 124 may be implemented as a Web server that serves Webpages to provide a user interface for processing service 104.

Processing service 104 may be implemented as a stand-alone processexecuting on a network element, such as a server or intermediary device.Processing service 104 may also be implemented on a client device,including client device 102, as depicted in FIG. 1E. In this example,processing service 104 is implemented on the client device 102 that isacquiring the image and/or video data and identification data.

III. Client Device Configuration and Data Acquisition

Client device 102 is configured to transmit acquired data to processingservice 104. The particular configuration required may vary dependingupon the particular transmission mechanism used. FIG. 2 is a flowdiagram 200 that depicts an approach for configuring client device 102to transmit acquired data to processing service 104. In step 202, a userselects to configure communications parameters for client device 102.This may be accomplished, for example, by a user selecting a control onuser interface 112 to access other controls for selecting communicationsparameters to be used by client device 102. As one example, a user mayaccess a menu that offers a choice of SMPT (Email), FTP or http. In step204, the user selects a particular data transfer method. In step 206, ifSMTP (Email) is selected as the data transfer method, then in step 208,the user is provided access to set SMTP (Email) parameters. This mayinclude, for example, an email address associated with processingservice 104 to which emails with acquired data will be sent. In step210, if FTP is selected as the data transfer method, then in step 212,the user is provided access to specify FTP parameters that may include,for example, an FTP server name, an FTP folder name and FTP credentials.In step 214, http is selected as the data transfer method, then in step216, the user is provided access to specify hap parameters, for example,a URL address to which acquired data may be posted. Although embodimentsare described herein in the context of client device 102 beingconfigured locally, i.e., via client device 102, client device 102 mayalso be configured remotely from another device. In this situation, auser of a remote device contacts client device 102 and accessesconfiguration options provided by a software application executing onclient device 102. This may include authenticating a user prior togranting the user access to the software application for configuringclient device 102. Client device 102 may be configured to supportmultiple data transfer methods.

Once client device 102 has been configured to transmit acquired data toprocessing service 104, data acquisition may be performed. FIG. 3A is aflow diagram 300 that depicts an approach for acquiring data with aclient device and transferring the acquired data to a processingservice. In step 302, identification data is acquired for an object.Referring to FIG. 1A, a user of client device 102 invokes the dataacquisition component 114 of client device 102 to acquire identificationdata that uniquely identifies object 116. For example, a user may selecta button or other control on client device 102, including a graphicaluser interface control, to cause client device 102 to scanidentification data for object 116, such as a number, code, etc. Theidentification data may be encoded, for example, in the form of abarcode, QR code, signature, etc. For example, suppose that clientdevice 102 is a camera, smartphone or tablet computer with a scanner. Inthe auto insurance context, a user, such as an insurance adjustor orautomobile repairman, uses the scanner on the camera, smartphone ortablet computer to scan a vehicle identification number (VIN) of anautomobile or a part of an automobile involved in an accident. Asanother example, in the EMR context, a user, such as a physician, nurseor medical administrative staff, uses the scanner on the camera,smartphone or tablet computer to scan a patient identification number, aphysician identification number, or both a patient and physicianidentification numbers. The data acquisition component 114 may beconfigured to generate scan data that may be in a wide variety offormats that may vary depending upon a particular implementation. Forexample, the scan data may be in an image data format, such as JPEG,TIFF, RAW, GIF, BMP, PNG, or in PDF.

In step 304, photo data and/or video data is acquired for the subjectobject. Referring to FIG. 1A, a user causes client device 102 to acquirephoto data and/or video data of object 116. This may include the userselecting one or more buttons or controls on client device 102 toactivate a camera or video recorder on client device 102 to acquire thephoto data and/or the video data of object 116. Referring again to theprior example where client device 102 is a camera, smartphone or tabletcomputer, in the auto insurance context, a user, such as an insuranceadjustor or automobile repairman, uses the camera, smartphone or tabletcomputer to take photos or video of an automobile or a part of anautomobile involved in an accident. FIGS. 4A and 4B are example photosof an automobile that has been involved in an accident. FIGS. 4C and 4Dare example photos of a location of an automobile accident. As anotherexample, in the EMR context, a user, such as a physician, nurse ormedical administrative staff, uses the camera, smartphone or tabletcomputer to take photos or video of a patient. The image and/or videodata may be in any of a wide variety of formats that may vary dependingupon a particular implementation. Example image data formats include,without limitation, JPEG, TIFF, RAW, GIF, BMP, PNG, etc., and examplevideo data formats include, without limitation, H.26X, M-PEG-X, etc.

In step 306, memorandum (memo) or other data for the object is acquiredand/or added to supplement the acquired photo or video data. The memo orother data may include a wide variety of data that may vary dependingupon a particular implementation. Memo or other data may be entered by auser via the user interface 112 of client device 102. For example,client device 102 may display a graphical user interface that allows auser to type alphanumeric characters into one or more text fields, orinto a form. For example, in the auto insurance context, a user, such asan insurance adjustor or automobile repairman, may enter an insuranceclaim number, a vendor name, a part cost and point-of-sale orpoint-of-service (POS) barcode number for the part.

FIG. 5A depicts a table of example memo information that may be enteredby a user for an automobile involved in an accident. As another example,in the EMR context, a user, such as a physician, nurse or medicaladministrative staff, may enter information associated with the patient,such as physician or staff notes about the patient, current medications,allergies, etc. FIG. 5B depicts a table of example memo information thatmay be entered by a user for a patient in the EMR context.

The information may also include annotation information for acquiredimage data and video data. For example, FIG. 6A depicts a graphical userinterface of a client device in the form of a camera that displays aregion on a patient's body. The camera includes a capability for a user,such as a physician, to annotate the picture to identify an area ofinterest, as depicted in FIG. 6B. This may be accomplished, for example,using user interface controls on the camera. Alternatively, the cameramay be configured with a touch screen and the physician or other medicalpersonnel may annotate the photo using a stylus or finger. Theannotation information is represented by data that may be transmitted tothe processing service 104 with the photo data.

An example of other data that may be acquired for the object is locationdata. For example, client device 102 may include a GPS component that iscapable of determining the current location of client device 102 andgenerate data that indicates the GPS coordinates of the client device102. This information may be helpful in a wide variety of contexts. Forexample, in the auto insurance context, the location information may beused to confirm the location of the accident and/or the automobile. Thelocation information may also include a name of a location. For example,in the EMR context, a user may use client device 102 to scan a barcodeor QR code of an examination room, emergency room, etc., to acquireinformation about the location where the image and/or video data wasacquired. In this example, the barcode may specify the name of a medicalfacility and/or room or location within the medical facility. Thisinformation may be later used to verify the exact location where theimage and/or video data was acquired. The other information may alsoinclude timestamp information that may be used to document when theimage and/or video data were acquired. The other information may alsoinclude data that identifies a user of client device 102. The user datamay be obtained when the user accesses client device 102 or when theuser accesses an application on client device 102 for acquiring imageand/or video data and identification data.

In step 308, client device 102 transfers the acquired data to processingservice 104. This may include the image and/or video data, as well asthe memo or other data acquired at client device 102. Client device 102may transfer the data to processing service 104 using any of thetechniques described herein, for example, via FTP, via email, or viahttp POST commands. The approach depicted in FIG. 3A may also include auser selecting an external service to which the acquired identificationdata, photo data, video data and memo and other data is to betransferred. In this situation, data identifying the selected externalservice is provided to processing service 104.

The particular user interface employed to support the acquisition ofobject identification, image data and video data and the transfer ofthat data to an external service may vary depending upon a particularimplementation and embodiments are not limited to any particularimplementation. FIG. 3B depicts an example graphical user interface 350that allows a user to select image data and scan data acquired at thesite of an automobile accident and transfer the selected image data andscan data to an auto insurance service. FIG. 3B is depicted anddescribed in the context of selecting image data for purposes ofexplanation only and embodiments are not limited to image data per seand are applicable to other types of data, such as video data. Thegraphical user interface 350 for sending data to a service includes aset of controls 352 for selecting data and a set of controls 354 forselecting a service to receive the selected data.

In this example, a user, such as a law enforcement person or aninsurance person, has used client device 102 to acquire scan data andimage data for an automobile accident involving a first automobile and asecond automobile. In this example, it is presumed that the user has thenecessary credentials to use client device 102 in this manner and thatthe user has been properly authorized to access client device 102. Theuser has scanned the VIN number of a first automobile involved in theaccident (“Scan 001”). The user has also taken three photos that includethe first automobile (“Image 001”), the second automobile (“Image 002”)and the accident location (“Image 003”). As indicated in FIG. 3B by thedashed boxes, the user has selected all three images and the scan datafor transfer and has selected the service “Auto Insurance Service #2” toreceive the data. The set of controls 352 also allows a user to add memodata and include location (loc) information with the acquired data. Inthe present example, the user has selected to add memo data and locationinformation for the photo of the first automobile (“Image 001”). Thememo information may be specified by the user via another graphical userinterface screen that is not depicted in FIG. 3B. For example, inresponse to the user selecting the “Add Memo” box adjacent “Image 001”,a dialog box may be displayed that allows the user to enter memo datafor “Image 001”. The location information may be provided by a locationcomponent of client device 102.

A set of user interface controls 356 allow the user to confirm thetransfer to the selected service or cancel the transfer. Upon confirmingthe transfer, the acquired data, which in the present example includesthe three images and the scanned VIN number of the first automobile, thememo data and the location data for “Image 001”, are sent to processingservice 104. User identification data that identifies a user of clientdevice 102 may also be sent to processing service 104. The inclusion ofdata that indicates the selected external service, i.e., Auto InsuranceService #2, allows processing service 104 to route the image data andother data to Auto Insurance Service #2. The transferring of the VINnumber of the first automobile with the images and other informationallows the images and other information to be associated with data, forexample an insurance claim record, maintained by the external service,i.e., Auto Insurance Service #2. In the example depicted in FIG. 3B, auser is given the capability to associate scan data with image data, butthis is not required. For example, in some embodiments, the userinterface 112 of client device 102 may prompt a user to first scan datathat uniquely identifies object 116, such as an identification or serialnumber, bar code, QR code, etc., and then take one or more photos orvideos of object 116. In this situation, the scanned data may beautomatically associated with and transmitted to processing service 104with the corresponding photos or videos.

There is no particular form or order in which the image or video dataand identification data for object 116 are transmitted by client device102 to processing service 104. For example, a user of client device 102may use a camera of client device 102 to first acquire image or videodata of object 116 and then use the data acquisition component 114 toacquire the identification data for object 116, for example, by scanninga bar code, QR code, etc., for object 116. The image or video data andidentification data may be transmitted by client device 102 toprocessing service 104 separately or together, depending upon aparticular implementation.

IV. Data Reception and Processing

As previously described herein, client device 102 may transfer acquireddata to processing service 104 using a wide variety of methods. FIGS.7A-7C are flow diagrams that depict example approaches for processingservice 104 to receive acquired data from client device 102. The flowdiagram of FIG. 7A corresponds to processing service 104 receivingacquired data from client device 102 using FTP, as previously describedherein with respect to FIG. 1B. In this approach, it is presumed that anFTP folder has been created on storage 126. The approach is described inthe context of a single FTP folder for purposes of explanation only, andthe approach is applicable to any number of FTP folders.

In step 702, processing service 104, or a component thereof, monitorsthe FTP folder to determine whether new data has been received fromclient device 102. The new data may include object identification data,image data, video data, other data, such as user identification, memo,location and timestamp data, as well as data that indicates a targetexternal service.

In step 704, when new data is detected, then processing service 104retrieves the new data from the FTP folder and in step 706 createsand/or updates record data. Various types of record data may be storedand maintained by processing service 104 and the format and content ofrecord data maintained by processing service 104 may vary depending upona particular implementation. Record data may be stored and managed onstorage 126 as acquired data 128. Data stored on storage 126, includingacquired data 128, may be stored in a secure manner, for example, usingencryption. This may be helpful in situations where data stored onstorage 126 includes sensitive information such as personal medicalinformation or other information that might pertain to legal claims,such as automobile accident information. Data may be stored on storage126 in a manner to comply with regulatory requirements. For example,regulatory requirements may specify a particular format and/orencryption that is to be used for certain types of data, such as medicalinformation.

FIG. 8A depicts an example data structure implemented by processingservice 104 in the auto insurance context. In this example, a user tableincludes, for each user, a user identification (ID), an authenticationtoken, such as a password, and FTP folder for the user and an emailaddress. The user table is associated with an insurance claim item thatincludes a user ID, a barcode, memo data, an ImageLink that provides alink to images for the insurance claim, a status and location data inthe form of GPS data. In FIG. 8A, the user table is indexed by a primarykey (PK) associated with a user. A value of the PK is indicated by anidentifier (ID). The user table may store data for one or more users,and may therefore have one or more entries, each entry having a uniqueID. The insurance claim item table may be indexed by a primary key (PK),which may correspond to the same PK in the user table.

FIG. 8B depicts an example data structure implemented by processingservice 104 in the EMR context. In this example, a user table is thesame as the user table depicted in FIG. 8A and includes, for each user,a user identification (ID), an authentication token, such as a password,and FTP folder for the user and an email address. The user table isassociated with a patient image item that includes a user ID, a barcode,memo data, an ImageLink that provides a link to images for the insuranceclaim, a status and location data in the form of GPS data. The patientimage item data structure may be indexed by a primary key (PK), whichmay correspond to the same PK in the user table of FIG. 8B.

In step 706, processing service 104 determines whether the dataretrieved from the FTP folder is new data and if so, creates and storeson storage 126, a new record for the user. If the data retrieved fromthe FTP folder is for an existing record, for example additional photosfor an insurance claim, then processing service 104 updates the existingrecord.

In step 708, processing service 104 schedules an external system updatewhich, when processed, causes the data acquired by client device 102 tobe provided to auto insurance system 106, EMR system 108 or otherservices 110, as described in more detail hereinafter. Scheduling anexternal system update may include a variety of steps that may varydepending upon a particular implementation. For example, scheduling anexternal system update may include generating and storing an entry in aprocessing queue, updating a flag, or otherwise notifying integrationservice 120. FIGS. 7B and 7C are flow diagrams that depict a processsimilar to the process depicted by the flow diagram of FIG. 7A, exceptin the context of transmitting data acquired by client device 102 viaemail or via http POST commands, respectively. In step 712 of FIG. 7B,processing service 104, or a component thereof, determines whether anemail has been received that contains new data. This may include, forexample, communicating with email client 136 to determine whether anemail has been received that includes new data from client device 102.In step 722 of FIG. 7C, processing service 104, or a component thereof,determines whether new data has been received from client device 102 viaan http POST. This may include, for example, determining whether an httpPOST command has been received at a specified URL, or by communicatingwith Web server 140 to determine whether an http POST command has beenreceived. Steps 714-718 of FIG. 7B and steps 724-728 of FIG. 7C aresimilar to steps 704-708 of FIG. 7A.

V. Transferring Acquired Data to External Services

According to one embodiment, integration service 120 is configured totransmit acquired data to external services, such as auto insurancesystem 106, EMR system 108 and other services 110. FIG. 9 is a flowdiagram 900 that depicts an approach for transferring acquired data toexternal services. In step 902, a check is made to determine whereupdates are needed. This may be performed using various approaches. Forexample, integration service 120 may determine whether a processingqueue contains an entry that is waiting to be processed. As anotherexample, integration service 120 may check for a flag or other type ofnotification that indicates that acquired data is ready to betransferred to an external service. Acquired data stored by processingservice 104 may be prioritized for transfer to external services. Apriority may be assigned to each set of acquired data received from aclient device. A priority level may be specified by a user of a clientdevice, for example, by specifying via user interface 112 that acquireddata is high priority. Data indicating the priority is transferred fromthe client device to processing service 104 and stored with the acquireddata so that acquired data stored at processing service 104 may beprocessed based upon the specified priorities. This may be useful insituations where it is helpful to process acquired data on an expeditedbasis. For example, a situation may exist where it is important toimmediately process acquired data for a particular patient, or toprocess data for a particular auto accident.

Assuming that an update is needed, then in step 904, acquired data isretrieved from records. For example, integration service 120 mayretrieve acquired data from records stored on storage 126. In step 906,information is updated on one or more external services. For example,integration service 120 may transfer to one or more of auto insurancesystem 106, EMR system 108 or other services 110, data contained intables stored on storage 126. In step 908, image and/or video data isuploaded to the external services, such as auto insurance system 106,EMR system 108 or other services 110.

The updating and uploading performed in steps 906 and 908 may includeformatting the acquired data to according to a data format supported bythe external service to which the acquired data is being transmitted.For example, auto insurance system 106 may require that uploaded data bein a particular format or include specified fields in a particular orderthat may be different than EMR system 108. As another example, someexternal services may require that uploaded data be formatted in asecure manner. For example, EMR system 108 may require that uploadeddata be encrypted using a particular encryption technique and/or aparticular encryption key. The updating and uploading of acquired datamay be performed in accordance with a particular API supported by theexternal services. For example, auto insurance system 106 may support aparticular API that specifies commands for creating an auto insuranceclaim record on auto insurance system 106, updating the claim recordwith information and for uploading image and/or video data to autoinsurance system 106. According to one embodiment, integration service120 formats the data in accordance with a particular format and/or APIrequired by an external service and invokes data transmitter 122 tocause the formatted data to be transmitted to the external service.

The approaches described herein are applicable to any number and typesof client devices. Processing service 104 may receive acquired data frommultiple client devices of different types, process the acquired dataand integrated the acquired data into multiple external services, suchas auto insurance system 106, EMR system 108 and other services 110.This may provide significant benefits in a wide variety of industries.For example, auto insurance companies may benefit from implementingprocessing service 104 within their information technology systems toallow their field agents, appraisers and third party repair services totake photos of automobiles involved in accidents and have those photosautomatically integrated into the insurance claim processing systems ofthe auto insurance companies. As another example, medical insurancecompanies may benefit from implementing processing service 104 withintheir information technology systems to allow physicians and othermedical personnel to take photos of patients and have those photosautomatically integrated into the claims processing systems of themedical insurance companies. Alternatively, processing service 104 maybe implemented as a third party service that is used by multiple autoand medical insurance companies.

VI. Processing Service Administration

According to one embodiment, processing service 104 is configured toprovide an administrative user interface for performing variousadministrative functions. Example administrative functions include,without limitation, viewing and managing histories of the acquired datatransferred to external services, viewing and managing error logs,managing user information and other functions. The administrative userinterface may be implemented by user interface 124 in various forms thatmay vary depending upon a particular implementation. For example, theadministrative user interface may be implemented by one or more APIssupported by user interface 124. As another example, the administrativeuser interface may be implemented as a Web interface. In this example,user interface 124 includes the capability to generate and transmit to aclient device one or more Web pages that implement the administrativeuser interface.

FIG. 10 depicts an example administrator login screen 1000 that may beimplemented as a Web page by user interface 124. In this example, a useris queried to enter a user ID and password that are authenticated byprocessing service 104 prior to granting access to the administrativefunctions provided by processing service 104. FIGS. 11A and 11B depictexample administrative user interface screens 1100, 1150 in the autoinsurance context. In FIG. 11A, screen 1100 depicts a Web page thatincludes a menu of four options: Upload History, Error Log, UserInformation and Administration. In screen 1100, a user has selected theUpload History option and the Upload History is displayed. In thisexample, the upload history includes four entries, each entrycorresponding to an upload of acquired data to auto insurance system106. The acquired data for each upload includes a VIN number of asubject automobile, memo data, an upload time, location data in the formof GPS data and an image. Two of the data uploads pertain to insuranceclaim #14322 and the other two data uploads pertains to two otherinsurance claims. In this example, the VIN number, memo data, or both,may be used to associate the upload data with data stored in autoinsurance system 106.

In screen 1150 of FIG. 11B, a user has selected the Error Log option andan error log is displayed that includes two entries. In this example,the error log indicates the data uploads for which an error occurredduring the upload. For example, a network communication error or anerror with auto insurance system 106 may have prevented acquired datafrom being successfully uploaded. The User Information option may allowan administrator to specify authorization information for users that areauthorized to access processing service 104. This may include, forexample, access constraints and data transfer constraints for users.

FIGS. 12A and 12B depict example administrative user interface screens1200, 1250 in the EMR context. The particular examples depicted in FIGS.11A, 11B, 12A and 12B are provided for explanation purposes only andembodiments are not limited to these examples. The particular userinterfaces implemented by user interface 124 may vary depending upon aparticular implementation.

VII. Implementation Mechanisms

Embodiments described herein are implemented by one or morespecial-purpose computing devices. The special-purpose computing devicesmay be hard-wired to perform the techniques, or may include digitalelectronic devices such as one or more application-specific integratedcircuits (ASICs) or field programmable gate arrays (FPGAs) that arepersistently programmed to perform the techniques, or may include one ormore general purpose hardware processors programmed to perform thetechniques pursuant to program instructions in firmware, memory, otherstorage, or a combination. Such special-purpose computing devices mayalso combine custom hard-wired logic, ASICs, or FPGAs with customprogramming to accomplish the techniques. The special-purpose computingdevices may be desktop computer systems, portable computer systems,handheld devices, networking devices or any other device thatincorporates hard-wired and/or program logic to implement thetechniques.

For example, FIG. 13 is a block diagram that illustrates a computersystem 1300 upon which an embodiment of the invention may beimplemented. Computer system 1300 includes a bus 1302 or othercommunication mechanism for communicating information, and a hardwareprocessor 1304 coupled with bus 1302 for processing information.Hardware processor 1304 may be, for example, a general purposemicroprocessor.

Computer system 1300 also includes a main memory 1306, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 1302for storing information and instructions to be executed by processor1304. Main memory 1306 also may be used for storing temporary variablesor other intermediate information during execution of instructions to beexecuted by processor 1304. Such instructions, when stored innon-transitory storage media accessible to processor 1304, rendercomputer system 1300 into a special-purpose machine that is customizedto perform the operations specified in the instructions.

Computer system 1300 further includes a read only memory (ROM) 1308 orother static storage device coupled to bus 1302 for storing staticinformation and instructions for processor 1304. A storage device 1310,such as a magnetic disk or optical disk, is provided and coupled to bus1302 for storing information and instructions.

Computer system 1300 may be coupled via bus 1302 to a display 1312, suchas a cathode ray tube (CRT), for displaying information to a computeruser. An input device 1314, including alphanumeric and other keys, iscoupled to bus 1302 for communicating information and command selectionsto processor 1304. Another type of user input device is cursor control1316, such as a mouse, a trackball, or cursor direction keys forcommunicating direction information and command selections to processor1304 and for controlling cursor movement on display 1312. This inputdevice typically has two degrees of freedom in two axes, a first axis(e.g., x) and a second axis (e.g., y), that allows the device to specifypositions in a plane.

Computer system 1300 may implement the techniques described herein usingcustomized hard-wired logic, one or more ASICs or FPGAs, firmware and/orprogram logic which in combination with the computer system causes orprograms computer system 1300 to be a special-purpose machine. Accordingto one embodiment, the techniques herein are performed by computersystem 1300 in response to processor 1304 executing one or moresequences of one or more instructions contained in main memory 1306.Such instructions may be read into main memory 1306 from another storagemedium, such as storage device 1310. Execution of the sequences ofinstructions contained in main memory 1306 causes processor 1304 toperform the process steps described herein. In alternative embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement embodiments described herein. Thus,embodiments are not limited to any specific combination of hardwarecircuitry and software.

The term “storage media” as used herein refers to any non-transitorymedia that store data and/or instructions that cause a machine tooperation in a specific fashion. Such storage media may comprisenon-volatile media and/or volatile media. Non-volatile media includes,for example, optical or magnetic disks, such as storage device 1310.Volatile media includes dynamic memory, such as main memory 1306. Commonforms of storage media include, for example, a floppy disk, a flexibledisk, hard disk, solid state drive, magnetic tape, or any other magneticdata storage medium, a CD-ROM, any other optical data storage medium,any physical medium with patterns of holes, a RAM, a PROM, and EPROM, aFLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 1302. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Various forms of media may be involved in carrying one or more sequencesof one or more instructions to processor 1304 for execution. Forexample, the instructions may initially be carried on a magnetic disk orsolid state drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 1300 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 1302. Bus 1302 carries the data tomain memory 1306, from which processor 1304 retrieves and executes theinstructions. The instructions received by main memory 1306 mayoptionally be stored on storage device 1310 either before or afterexecution by processor 1304.

Computer system 1300 also includes a communication interface 1318coupled to bus 1302. Communication interface 1318 provides a two-waydata communication coupling to a network link 1320 that is connected toa local network 1322. For example, communication interface 1318 may bean integrated services digital network (ISDN) card, cable modem,satellite modem, or a modem to provide a data communication connectionto a corresponding type of telephone line. As another example,communication interface 1318 may be a local area network (LAN) card toprovide a data communication connection to a compatible LAN. Wirelesslinks may also be implemented. In any such implementation, communicationinterface 1318 sends and receives electrical, electromagnetic or opticalsignals that carry digital data streams representing various types ofinformation.

Network link 1320 typically provides data communication through one ormore networks to other data devices. For example, network link 1320 mayprovide a connection through local network 1322 to a host computer 1324or to data equipment operated by an Internet Service Provider (ISP)1326. ISP 1326 in turn provides data communication services through theworld wide packet data communication network now commonly referred to asthe “Internet” 1328. Local network 1322 and Internet 1328 both useelectrical, electromagnetic or optical signals that carry digital datastreams. The signals through the various networks and the signals onnetwork link 1320 and through communication interface 1318, which carrythe digital data to and from computer system 1300, are example forms oftransmission media.

Computer system 1300 can send messages and receive data, includingprogram code, through the network(s), network link 1320 andcommunication interface 1318. In the Internet example, a server 1330might transmit a requested code for an application program throughInternet 1328, ISP 1326, local network 1322 and communication interface1318.

The received code may be executed by processor 1304 as it is received,and/or stored in storage device 1310, or other non-volatile storage forlater execution.

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromimplementation to implementation. The specification and drawings are,accordingly, to be regarded in an illustrative rather than a restrictivesense. The sole and exclusive indicator of the scope of the invention,and what is intended by the applicants to be the scope of the invention,is the literal and equivalent scope of the set of claims that issue fromthis application, in the specific form in which such claims issue,including any subsequent correction.

What is claimed is:
 1. A device comprising: one or more data acquisitioncomponents configured to: capture an image of an object, and acquireobject identification data that uniquely identifies the object; and atouchscreen user interface configured to: display information to a userof the device capturing the image of the object and receive user inputfrom the user of the device, display the captured image of the object,allow a user of the device to use a finger or stylus to create anannotation on the displayed captured image captured by the device toidentify an area of interest in the displayed captured image, and allowthe user of the device to enter memorandum information; wherein thedevice is further configured to: generate annotation data thatrepresents the annotation on the displayed captured image thatidentifies the area of interest, generate memorandum data thatrepresents the memorandum information, and cause the captured image ofthe object, the annotation data, and the memorandum data to betransmitted over one or more wireless communications networks to aprocessing service.
 2. The device of claim 1, wherein the annotationdata is transmitted with the captured image over the one or morewireless communications networks to the processing service.
 3. Thedevice of claim 1, wherein the memorandum information includesinformation pertaining to the object.
 4. The device of claim 1, whereinthe one or more data acquisition components include a scanner foracquiring the object identification data in an encoded form.
 5. Thedevice of claim 1, wherein: the one or more data acquisition componentsare configured to: determine a current location of the device at a timethat the image of the object was captured, and generate location datathat indicates the current location of the device at the time that theimage of the object was captured; and the device is further configuredto cause the location data to be transmitted over the one or morewireless communications networks to the processing service.
 6. Thedevice of claim 1, wherein the object identification data that uniquelyidentifies the object is encoded object identification data andrepresented by one or more of a bar code, a QR code, or a signature. 7.The device of claim 1, wherein the processing service is configured tocause the cause the captured image of the object and the annotation datato be transmitted over the one or more wireless communications networksto an electronic medical record system that is external to both thedevice and the processing service utilizing one or more applicationprogram interfaces that are supported by the electronic medical recordsystem and not supported by the device.
 8. An apparatus comprising: oneor more processors; one or more memories storing instructions which,when processed by the one or more processors, cause a processing serviceto perform: receiving, via one or more wireless communications networksfrom a mobile client device having at least a data acquisition componentthat includes a camera and is configured to acquire images of patientsand identification data that uniquely identifies the patients, and atouchscreen user interface configured to display the images of patientsacquired by the mobile client device and allow a user of the mobileclient device to create an annotation on the displayed acquired imagesacquired by the mobile client device to identify an area of interest inthe displayed acquired images, first image data that includes a firstset of images of a first patient, first identification data thatuniquely identifies the first patient and annotation data thatrepresents the annotation on the displayed acquired images thatidentifies the area of interest in the displayed acquired images,generating and storing first record data that includes the firstidentification data and at least a reference to the first image data,causing the first image data associated with the first patient, thefirst identification data that uniquely identifies the first patient,and the annotation data that represents the annotation on the displayedacquired images that identifies the area of interest in the displayedacquired images to be transmitted via one or more communicationsnetworks to an electronic medical record system that is external to theapparatus utilizing one or more application program interfaces that aresupported by the electronic medical record system and not supported bythe mobile client device, and generating and providing via the one ormore communications networks to a client device user interface datawhich, when processed at the client device, cause a graphical userinterface to be displayed on the client device, wherein the graphicaluser interface allows a user of the client device to view an uploadhistory for the electronic medical record system.
 9. The apparatus ofclaim 8, wherein the upload history for the electronic medical recordsystem includes a plurality of entries, wherein each entry from theplurality of entries corresponds to a patient and includesidentification data that uniquely identifies the patient, one or moreimages of the patient and memorandum data entered by a user of themobile client device when the one or more images of the patient wereacquired using the mobile client device.
 10. The apparatus of claim 8,wherein the graphical user interface further allows the user of theclient device to view an error log for the electronic medical recordsystem, wherein the error log specifies one or more errors that occurredwhen the first image data associated with the first patient and thefirst identification data that uniquely identifies the first patientwere transmitted via the one or more communications networks to theelectronic medical record system.
 11. The apparatus of claim 8, whereinthe graphical user interface further allows the user of the clientdevice to perform one or more administrative functions with respect tothe processing service.
 12. The apparatus of claim 8, wherein the one ormore memories store additional instructions which, when processed by theone or more processors, cause: performing one or more of monitoring afile transfer protocol (FTP) folder, monitoring an electronic mailfolder or receiving a hypertext transfer protocol (HTTP) post, and inresponse to detecting receipt of the first image data and the firstidentification data via the FTP folder, the electronic mail folder orthe HTTP post, retrieving the first image data and the firstidentification data from the FTP folder, the electronic mail folder orthe HTTP post.
 13. One or more non-transitory computer-readable mediastoring instructions which, when processed by one or more processors,cause: one or more data acquisition components of a mobile device to:capture an image of an object, and acquire object identification datathat uniquely identifies the object; and a touchscreen user interface ofthe mobile device to: display information to a user of the mobile devicecapturing the image of the object and receive user input from the userof the mobile device, display the captured image of the object, allow auser of the device to use a finger or stylus to create an annotation onthe displayed captured image captured by the device to identify an areaof interest in the displayed captured image, and allow the user of thedevice to enter memorandum information; the mobile device to: generateannotation data that represents the annotation on the displayed capturedimage captured by the mobile device that identifies the area ofinterest, generate memorandum data that represents the memoranduminformation, and cause the captured image of the object, the annotationdata, and the memorandum data to be transmitted over one or morewireless communications networks to a processing service.
 14. The one ormore non-transitory computer-readable media of claim 13, wherein theannotation data is transmitted with the captured image over the one ormore wireless communications networks to the processing service.
 15. Theone or more non-transitory computer-readable media of claim 13, whereinthe one or more data acquisition components include a scanner foracquiring the object identification data in an encoded form.
 16. The oneor more non-transitory computer-readable media of claim 13, furthercomprising additional instructions which, when processed by the one ormore processors, cause: the one or more data acquisition components ofthe mobile device to: determine a current location of the mobile deviceat a time that the image of the object was captured, and generatelocation data that indicates the current location of the mobile deviceat the time that the image of the object was captured; and the mobiledevice to cause the location data to be transmitted over the one or morewireless communications networks to the processing service.